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To  meet  information  needs  of  operational  commanders,  user-centric  applications  will  combine  Global  Information  Grid  (GIG) 
data  and  services  to  create  a  Common  Operational  Picture  (COP).  The  COP,  a  single  identical  display  of  relevant  information 
shared  ly  more  than  one  command,  will facilitate  collaborative  planning  and  situational  awareness.  Eand  warfare  decision-mak¬ 
ers  are  particularly  interested  in  ground  vehicle  mobility  characteristics  of  the  battlespace.  This  paper  describes  both  theMobility- 
COP,  from  which  warfighters  can  assess  the  ability  of  forces  to  maneuver  effectively  under  multiple  environmental  and  tactical 
conditions,  and  a  formal  ontology  design  to  achieve  the  Mobility-COP  in  the  future  GIG  net-centric  architecture. 


The  Global  Information  Grid  (GIG) 
[1]  is  emerging  as  the  next-genera¬ 
tion  architecture  for  making  military 
command,  control,  communications, 
computers,  intelligence,  surveillance  and 
reconnaissance  information  available  as 
discoverable  and  callable  services  to  a 
spectrum  of  users,  software  agents,  and 
software  systems.  To  meet  information 
needs  of  operational  commanders,  user¬ 
centric  applications  will  compose  GIG 
data  and  services  to  create  a  Common 
Operational  Picture  (COP),  defined  in 
Joint  Publication  (JP)  3-0  [2]  as,  “a  single 
identical  display  of  relevant  information 
shared  by  more  than  one  command.” 
The  COP  will  facilitate  collaborative 
planning  and  situational  awareness.  The 
COP  will  be  a  user-tailorable  selection, 
organization,  and  display  of  information 
obtained  from  diversely  distributed  data 
sources  and  services.  Users  across  the 
force  will  have  confidence  the  informa¬ 
tion  provided  in  their  respective  COPs  is 
drawn  from  consistent,  trusted  sources 
across  the  network. 

Land  warfare  decision-makers  are 
particularly  interested  in  representation 
of  ground  mobility  characteristics  of 
the  battlespace.  Using  these  characteris¬ 
tics,  warfighters  assess  the  ability  of 
forces  to  maneuver  effectively  under 
multiple  environmental  and  tactical  con¬ 
ditions.  This  portion  of  the  COP  is 
termed  the  Mobility-COP.  Although  a 
subset  of  the  overall  COP,  the  Mobility- 
COP  presents  a  challenging  mix  of 
information  provided  by  decision  aids, 
environmental  databases,  platform  per¬ 
formance  data,  doctrinal  behaviors,  and 
process  simulation.  These  sources  of 
data  and  services  use  a  variety  of  data 
models  that  need  to  be  reconciled 
through  metadata  and  data  mediation 
and  then  merged  to  create  the  Mobility- 


COP.  This  article  describes  the  Mobility- 
COP  and  discusses  development  of  an 
ontology  to  represent  the  data  and  infor¬ 
mation  requirements  of  the  Mobility- 
COP  within  the  GIG  architecture. 

Mobility-Common 
Operational  Picture 
Assured  Mobility 

Assured  mobility  is  a  Force  Operating 
Capability  identified  in  the  U.S.  Army 
Training  and  Doctrine  Command 
(TRADOC)  Pamphlet  525-66  for  future 
operational  environment  capabilities.  It 
states  the  assured  mobility  framework: 

...  includes  all  those  actions  that 
guarantee  the  force  commander 
the  ability  to  deploy,  move,  and 
maneuver,  by  ground  or  vertical 
means,  where  and  when  desired, 
without  interruption  or  delay,  to 
achieve  the  intent.  [3] 

The  assured  mobility  concept  ties 
into  the  larger  operational  framework  as 
an  overarching  enabler  supported  by  the 
various  battlespace  functions,  including 
Engineer  Battlespace  Functions  of 
Combat  Engineering  (mobility,  counter¬ 
mobility,  and  survivability).  Geospatial 
Engineering,  and  General  Engineering. 
Unification  of  data  and  information 
across  the  various  battlefield  operating 
systems  (BOS)  components  requires 
unification  of  conceptual  data  models 
across  software  systems  manipulating 
that  information.  Specifically,  a  common 
vocabulary  and  formalized  semantics  are 
needed  to  describe  ground  vehicle 
mobility  data  for  software  support  to 
movement  planning  and  mission  moni¬ 
toring.  Design  of  the  Mobility-COP 
ontology  serves  this  purpose,  identifying 


the  common  concepts  relating  ground 
vehicle  mobility  across  the  components 
in  the  operational  framework  for  assured 
mobility. 

The  following  are  the  four  impera¬ 
tives  of  assured  mobility  that  are  linked 
to  the  elements  of  combat  power  [4]: 

1.  Develop  mobility  input  to  the  COP. 

2.  Establish  and  maintain  operating 

areas. 

3.  Negate  the  influence  of  impedi¬ 
ments  on  operating  areas. 

4.  Maintain  mobility  and  momentum. 

The  first  assured  mobility  imperative, 

develop  mobility  input  to  the  COP,  serves  as 
the  impetus  for  defining  the  Mobility- 
COP.  Armed  with  identified  critical 
mobility  elements  for  the  COP,  the  com¬ 
mander  will  gain  improved  situational 
understanding  through  the  use  of 
geospatial  tools  that  combine  improved 
intelligence,  surveillance,  and  reconnais¬ 
sance  capabilities  with  terrain  data.  Each 
of  the  four  imperatives  for  assured 
mobility  has  implications  for  what 
mobility-related  data  and  information 
are  needed  for  the  Mobility-COP.  These 
concepts  provide  insights  and  serve  as  a 
guide  for  further  analysis,  organization, 
and  scoping  of  the  Mobility-COP. 

More  formally,  the  Mobility-COP  is 
defined  as  a  subset  of  the  COP  consist¬ 
ing  of  relevant  movement  and  maneuver 
data  and  information  shared  by  more 
than  one  command  [5].  The  Mobility- 
COP  can  be  tailored  for  various  users 
and  includes  data  and  information  for 
mobility  of  individual  combatants, 
ground  vehicles,  and  autonomous/ 
robotic  vehicles.  Interoperability  across 
battle  command  systems  and  simula¬ 
tions  for  mission  planning  and  embed¬ 
ded  training  cannot  be  achieved  without 
effective  sharing  of  data  and  computa¬ 
tional  services.  Effective  sharing  implies 
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the  ability  to  express  concepts  that  can 
be  understood  by  diverse  data  sources 
and  services. 

With  the  requirement  to  enable  inter¬ 
actions  across  multiple  existing,  emerg¬ 
ing,  and  rapidly  adapting  systems,  it  is  no 
longer  possible  to  hard-code  all  systems 
to  a  single  common  data  model.  In  con¬ 
trast,  given  a  common  core  data  model, 
it  is  feasible  for  multiple  systems  to  use 
adaptors  and  mediation  services  to 
express  system-dependent  concepts  in 
the  common  interchange  language.  For 
this  reason,  development  of  a  formal 
ontology  for  the  Mobility-COP  will  pro¬ 
vide  a  defined  vocabulary  and  common 
semantics  to  serve  as  the  basis  for 
required  interoperability.  Following  GIG 
guidelines,  subsequent  submission  of 
the  ontology  to  the  Department  of 
Defense  (DoD)  Metadata  Registry  and 
Clearinghouse'  will  make  the  model 
available  to  other  domains. 

Elements  of  the 

Mobility-COP 

Ontology 

The  Mobility-COP  design  team  initially 
conducted  a  review  and  analysis  of  doc¬ 
trine,  data  structures,  standards  and  sys¬ 
tems  regarding  ground  vehicle  mobility 
and  maneuver.  This  analysis  resulted  in 
an  initial  slate  of  data  categories  and  fea¬ 
tures/  attributes  for  the  Mobility-COP. 
Other  data  sources  and  standards  which 
provided  sub-elements  or  attributes  to 
the  above  categories  were  examined; 
these  included  the  data  dictionary  of  the 
Force  XXI  Battle  Command  Brigade 
and  Below,  the  OneSAF  Objective 
System  (OOS)  Environmental  Data 
Model  (EDM),  as  well  as  Commercial 
Joint  Mapping  Tool  Kit  Battlespace 
Terrain  Reasoning  and  Analysis  (BTRA) 
products.  A  systems  engineering-based 
process  was  conducted  to  obtain  input 
from  subject  matter  experts  and  stake¬ 
holders  as  a  critical  part  of  determining 
the  elements  and  a  hierarchical  structure. 
The  assured  mobility  imperatives  dis¬ 
cussed  previously  and  the  Army 
Universal  Task  List  were  used  as  part  of 
the  process.  Analysis  of  the  inputs  from 
the  participants  resulted  in  eight  top- 
level  categories  of  information  defined 
in  Table  1 . 

Emerging  concepts  and  capabilities 
of  the  GIG,  as  well  as  current  and 
emerging  standards  and  tools,  were 
investigated  to  define  what  is  meant  by  a 
Mobility-COP  relative  to  data,  specifica¬ 
tions,  and  Web  services.  To  the  extent 
possible,  the  Mobility-COP  will  reuse 


applicable  standards,  tools,  and  products 
rather  than  developing  these  over  again. 
It  is  also  not  the  intent  of  this  work  to 
define  or  redefine  geospatial  features 
and  attributes  that  are  found  in  existing 
standards,  or  to  manipulate  or  normalize 
them.  Recent  publications  by  Dobey  and 
Eirich  [6]  and  Miller  and  Birkel  [7]  dis¬ 
cuss  issues  associated  with  geospatial 
data  and  its  representation  and  source, 
vis-a-vis  the  GIG.  Our  current  intent  is 
to  represent  terrain  features  within  the 
Mobility-COP  using  the  OOS  EDM 
based  on  the  Environmental  Data 
Coding  Specification  (EDCS).  The  work 
of  Dobey,  Eirich,  and  Loaiza,  [8]  relat¬ 
ing  to  environmental  extension  to  the 
Command  and  Control  Information  Ex¬ 
change  Data  Model  (C2IEDM),  using 
the  EDCS,  is  also  relevant  to  Mobility- 
COP  development.  Other  related 
ontologies  currently  under  development 
include  a  synthetic  environment  repre¬ 
sentation  [9]  and  a  DoD  core  taxonomy 
[10]. 

Mobility-COP  Ontology 
Development 

Noy  and  McGuinness  [11]  describe  the 
development  of  ontologies  in  a  step-by- 
step  process.  The  first  step  is  to  deter¬ 
mine  the  domain  and  scope  of  the 
ontology.  We  used  their  process,  com¬ 
bined  with  subsequent  analysis,  to  devel¬ 
op  a  hierarchal  structure  based  on  the 


BOS  combined  with  competency  ques¬ 
tions  (which  a  knowledge  base  should 
help  answer).  Based  on  the  U.S.  Army 
Operations  Order  format,  an  initial  list 
of  competency  questions  was  generated: 

•  Where  are  the  obstacles  to  maneu¬ 
ver? 

•  What  are  effects  of  terrain  and 
weather  on  friendly  (or  enemy) 
ground  vehicle  maneuver? 

•  Where  are  the  friendly  (or  enemy) 
avenues  of  approach? 

•  Where  is  the  key  terrain  for  friendly 
(or  enemy)  maneuver  (e.g.  mobility 
choke  points,  bridges)? 

•  What  are  the  effects  of  observation 
and  fields  of  fire  on  maneuver? 

These  questions  assume  that  the  area  of 
operations  and  the  mission  are  known  in 
terms  of  the  five  W’s  [12]:  who,  what, 
when,  where,  and  why.  This  leads  to  the 
next  step  in  the  development  of  an 
ontology:  the  reuse  of  existing  ontolo¬ 
gies.  The  C2IEDM  is  an  internationally 
accepted  data  modeP,  and  recent  studies 
have  investigated  the  development  and 
sufficiency  of  the  C2IEDM  ontology 
[13].  Although  the  concepts  of  maneu¬ 
ver  analysis  and  mobility  are  not  well 
represented,  it  offers  much  of  the  con¬ 
text  required  for  the  Mobility-COP 
ontology. 

Tolk  and  Blais  [14]  describe  a  taxon¬ 
omy  as  a  tree  structure  of  classifications  for  a 
given  set  of  objects,  and  an  ontology  as  an 


Table  1:  Mobility-COP  Top-Cevel  Categories 


Categories 

Definitions 

Terrain 

The  natural  and  manmade  features  and  their  attributes  that  may 
influence  mobility  or  manuever  of  ground  vehicles. 

Obstacles 

Those  terrain  features  or  other  objects  or  conditions  that  disrupt  or 
impede  movement  of  ground  vehicles. 

Weather 

Current  and  forecasted  weather  conditions  that  affect  mobility 
and  maneuver  (visibility,  precipitation). 

Maneuver 

Analysis 

The  results  of  an  analysis  to  ground  vehicle  movement  relative  to 
mission,  command  and  control,  local  culture,  and  other  considerations. 

Also  includes  information  classes  required  for  the  analysis. 

Route  Planning 

A  route  plan  (directions  for  moving  from  A  to  B),  the  results  of 
intermediate  steps  to  obtain  the  plan  and  a  subset  of  the 
required  data. 

Threat  Analysis 

The  location,  capabilities,  and  other  information  (potential  actions) 
relating  to  threats  to  maneuver  that  can  include,  in  addition  to  enemy 
forces,  local  populations,  and  cultural  effects. 

Forces 

Information  relating  to  manuever  and  transportation  units,  and 
individual  platform  locations  and  capabilities  as  related  to  mobility 
and  maneuver. 

Utilities 

Information  (metadata)  that  may  be  applicable  to  all  elements  of 
the  Mobility-Common  Operational  Picture. 
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attempt  to  formulate  an  exhaustive  and  rigor¬ 
ous  conceptual  schema  within  a  given  domain. 
A  key  distinction  is  that  an  ontology  is 
not  limited  to  a  tree  structure,  but  can 
represent  a  multiple  inheritance  hierar¬ 
chy.  For  example,  the  subclass  Minefield 
may  simultaneously  be  considered  a 
member  of  the  Obstacle  class  while  also 
being  a  member  of  a  terrain  or  facility 
class.  It  would  inherit  some  properties 
from  each  superclass. 

Table  1  presents  the  top-level  com¬ 
ponents  defined  thus  far.  The  following 
provide  descriptions  of  those  compo¬ 
nents  as  they  pertain  to  ground  vehicle 
mobility  and  maneuver  analysis. 

Terrain 

The  terrain  component  of  the  Mobility- 
COP  data  model  is  defined  as  the  natur¬ 
al  and  man-made  features  and  their 
attributes  which  may  influence  mobility 
or  maneuver  of  ground  vehicles.  Terrain 
includes  natural  and  man-made  features, 
where  man-made  features  include  mine¬ 
fields,  bridges,  roads,  etc.  Man-made 
objects  are  things  on,  in,  or  over  the  terrain 
(such  as  roads,  tunnels,  and  bridges, 
respectively)  and  need  to  be  distin¬ 
guished  from  the  underlying  physical 
terrain  (ground  and  water).  Due  to  the 
extensive  past  and  present  work  in  the 
area  of  terrain  data  modeling,  numerous 
representations  are  readily  available  that 


meet  portions  of  Mobihty-COP  require¬ 
ments.  These  models  have  many  com¬ 
plementary  representations  that  can  be 
mined  for  use  in  the  Mobility-COP; 
however,  they  also  possess  conflicting 
representations  that  need  to  be  resolved 
for  use  in  the  Mobility-COP. 

Obstacles 

Obstacles  consist  of  those  terrain  fea¬ 
tures  or  other  objects  or  conditions 
which  disrupt  or  impede  movement  of 
ground  vehicles.  As  with  terrain,  obsta¬ 
cles  may  be  natural  (cliff,  ravine,  swamp) 
or  man-made  (minefield,  log  barricade, 
rubble).  Some  Terrain  objects,  whether 
man-made  or  natural,  can  also  belong  to 
the  Obstacles  class  based  on  characteris¬ 
tics  that  cause  these  objects  to  disrupt  or 
impede  movement  of  ground  vehicles. 
With  an  automated  reasoned,  members 
of  various  classes  can  be  automatically 
classified  as  obstacles  based  on  their 
properties;  for  example,  a  river  with  cer¬ 
tain  width  and  depth  values  can  be  classi¬ 
fied  as  an  obstacle.  If  those  property  val¬ 
ues  change,  say  during  a  drought,  then 
the  river  may  cease  to  be  an  obstacle. 
Obstacles  are  also  fuUy  specified  in  exist¬ 
ing  data  models  (e.g.  Table  2)  and  can  be 
reused  for  Mobility-COP  purposes. 

Weather 

Weather  consists  of  current  and  fore¬ 


casted  weather  conditions,  which  effect 
mobility  and  maneuver  (visibility,  precip¬ 
itation).  This  component  has  a  similar 
structure  to  Terrain  in  that  it  is  best 
characterized  as  a  geographic  region 
having  certain  physical  and  temporal 
characteristics.  There  are  numerous  data 
representations  that  meet  Mobility-COP 
information  requirements. 

Maneuver  Analysis 

Maneuver  Analysis  includes  the  results 
of  analyses  related  to  ground  vehicle 
movement  with  respect  to  mission,  com¬ 
mand  and  control,  local  culture  and 
other  considerations.  Some  researchers 
have  observed  that  efforts  to  reach  com¬ 
mon  terrain  and  environment  models 
have  been  focused  at  the  data  level 
rather  than  at  the  information  or  knowl¬ 
edge  level.  The  distinction  is  important. 
Systems  have  primarily  dealt  directly 
with  the  raw  data  characterizing  a  geo¬ 
graphic  region,  performing  various  pro¬ 
cessing  to  derive  some  battlefield  effect 
(such  as  line-of-sight).  Rather  than  hav¬ 
ing  such  information  available  directly, 
numerous  systems  spend  processing 
resources  to  derive  the  higher-order 
effects  and  often  compute  those  results 
over  and  over  again.  Moreover,  the  raw 
data  are  extremely  large,  making  it  very 
inefficient  to  distribute  over  a  network. 
What  most  systems  really  require  is  not 
the  raw  data  itself,  but  the  derived  prod¬ 
ucts  (e.g.,  a  geometric  line-of-sight  enve¬ 
lope).  In  recognition  of  this  fact,  the 
U.S.  Army  Engineer  Research  and 
Development  Center’s  Topographic 
Engineering  Center  is  defining  a  data 
model  for  a  Geospatial  Battle 
Management  Language  that: 

...  seeks  to  abstract  and  represent 
terrain  and  dynamic  environment 
through  a  rich  set  of  discrete 
objects  (spatial  and  temporal)  and 
relationships  to  tactical  entities 
and  tasks.  [15] 

The  effect  will  be  to  reduce  large  terrain 
data  sets  to  their  tactical  essence  and 
express  the  reduction  in  an  ontology  for 
interoperability  at  the  conceptual  level. 
This  work  has  clear  relevance  to  the 
Mobility-COP  ontology  design  effort. 

Route  Planning 

Route  Planning  contains  the  route  plan 
(directions  for  moving  from  A  to  B),  the 
results  of  intermediate  steps  to  obtain 
this  plan,  and  a  subset  of  the  required 
data.  Derivation  of  the  routes  is  depen¬ 
dent  on  information  from  the  other 


Table  2:  Attributes  of  the  OneSAF  Objective  System  Finvironmental  Data  Model  Minefield  Area 
Feature*  (a  region  throughout  which  explosive  mines  have  been  laid) 


Attribute  Name 

Description" 

CASE_BURIAL_FRACTION 

The  fraction  of  the  case  that  is  buried  beneath  the  terrain. 

COMPLETION_PERCENTAGE 

The  extent  of  completion  in  terms  of  fractional  ascension 
from  start  of  construction  to  completion  of  construction. 

DURATION_OVERVIEW 

The  quantity  of  time  in  gross  sense  that  the  minefield  may 
be  assumed  to  be  active. 

EXPLOSIVE_MINE_TYPE 

The  type  of  explosive  mines  (e.g.  anti-tank,  anti-personnel). 

FORCEJDENTIFIER 

A  textual  identifier  of  a  military  or  civilian  force  (which  created 
the  minefield). 

GENERAL_DAMAGE_FRACTION 

The  extent  of  damage  to  the  minefield  in  terms  of  fractional 
degradation  from  a  fully  functional  state. 

MINE_ALLEGIANCE 

The  military  allegiance  of  the  force  responsible  for  the  creation 
or  maintenance  of  the  minefield. 

MINE_DENSITY 

The  areal  density  of  explosive  mines  within  the  minefield. 

Units  of  one  mine  per  square  meter. 

MINEFIELD_MARKING_TYPE 

Specifies  by  who  and  how  the  minefield  is  marked. 

NUMERIC_OBJECTJDENTIFIER 

The  numeric  identifier. 

PREPARED  EXPLOSIVE  DESTRUCTION 
_COMPLETION_FRACTION 

The  extent  to  which  the  minefield  has  been  prepared 

for  destruction  by  explosives  in  terms  of  fractional  completion. 

SOURCE 

The  source  from  which  the  data  were  captured  or  upgraded. 

UNIVERSALLY_UNIQUEJD 

Universally  unique  identifier,  guaranteed  to  be  unique  to  a 
specific  machine  (computer)  at  a  specific  time. 
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Mobility-COP  categories;  for  example, 
slope  information  from  terrain,  mine¬ 
field  placement  and  status  from  obsta¬ 
cles,  precipitation  and  temperature  from 
weather,  or  mission  and  own-force 
mobility  assets  from  forces.  The  BTRA 
software  is  a  current  decision  aid  per¬ 
forming  this  type  of  processing  to  gen¬ 
erate  route  plans.  Because  the  routes  are 
products  of  such  processing,  BTRA  can 
become  a  software  service  providing 
input  to  the  Mobility-COP  in  the  GIG 
environment. 

Threat  Analysis 

Threat  analysis  from  the  Mobility-COP 
point  of  view  describes  ways  in  which 
the  adversary  can  potentially  disrupt 
mobility  and  maneuver  during  the 
course  of  a  mission.  In  general,  these 
can  include  areas  to  be  avoided  (when 
safe  routes  are  desired)  or  approached 
(when  the  mission  is  to  attack).  For 
example,  a  fast,  safe  route  through  an 
urban  area  may  need  to  include  (in  route 
planning)  not  only  information  regard¬ 
ing  historical  improvised  explosive 
device  locations,  but  also  local  market 
events  (time  and  location).  The  chal¬ 
lenge  is  to  be  able  to  express  not  only 
known  threats  (the  physical  location  of 
an  enemy  force),  but  also  the  probability 
that  the  force  will  attempt  to  disrupt  a 
mission. 

Forces 

The  Forces  component  describes  infor¬ 
mation  relating  to  maneuver  and  trans¬ 
portation  units,  and  individual  platform 
locations  and  capabilities  as  related  to 
mobility  and  maneuver.  Since  the  repre¬ 
sentation  of  military  forces  is  a  key  ele¬ 
ment  of  Command,  Control,  Communi¬ 
cations,  Computers,  and  Intelligence  and 
modeling  and  simulation  (M&S)  sys¬ 
tems,  there  are  numerous  representa¬ 
tions  available  for  reuse  in  the  Mobility- 
COP  data  model.  Clearly  applicable  are 
the  XML  schema  representations  used 
in  the  Defense  M&S  Office  Unit  Order 
of  Batde  Data  Access  Tool  and  the 
Military  Scenario  Definition  Language 
(MSDL).  MSDL  is  used  for  scenario  ini¬ 
tialization  and  scenario  archival  storage 
in  OOS  and  has  recently  transitioned  to 
product  development  status  in  the  stan¬ 
dardization  process  of  the  Simulation 
Interoperability  Standards  Organization. 
Taxonomies  of  military  forces  are  also 
available  in  the  DoD  Metadata  Registry 
and  Clearinghouse. 

Utilities 

Utilities  refer  to  information  (metadata) 


that  is  applicable  to  all  elements  of  the 
Mobility-COP.  Since  the  Mobility-COP 
will  be  a  specialized  collection  of  infor¬ 
mation  and  services  from  the  distributed 
data  environment  rather  than  a  specific 
physical  data  structure  on  the  network, 
the  individual  components  making  up 
the  Mobility-COP  will  be  discoverable  in 
their  own  right  through  adherence  to  the 
DoD  Discovery  Metadata  Specification'. 
Furthermore,  specification  of  Mobility- 
COP  will  include  not  only  metadata 
descriptions  of  data  products,  but  will 
also  specify  Web-based  processes  using 
standards  adopted  for  use  in  the  GIG 
such  as  the  Web  Services  Description 
Language.  Currently  missing  from  iden¬ 
tified  GIG  standards  is  emphasis  on 
stronger  semantics  for  data  and  service 
description  and  service  composition 
through  the  use  of  semantic  Web  con¬ 
structs  such  as  the  Web  Ontology 
Language  and  the  Web  Ontology 
Language  for  Services.  Full  specification 
of  the  Mobility-COP  will  include  such 
representations  to  solidify  the  founda¬ 
tion  for  enhanced  interoperability. 

Summary 

The  Mobility-COP  ontology  is  a  specifi¬ 
cation  of  those  elements  within  the 
domain  of  ground  vehicle  mobility  and 
maneuver  analysis  essential  for  military 
decision  making,  battle  command  and 
simulation.  It  provides  a  representation 
of  ground  vehicle  mobility  data  within 
the  tenets  of  the  COP  and  the  GIG. 

To  help  achieve  assured  mobility  for 
the  Future  Force  in  a  net-centric  envi¬ 
ronment,  the  ability  to  publish,  access, 
process,  and  disseminate  mobility  and 
maneuver-related  data,  and  information 
among  battle  command,  modeling,  and 
simulation  systems  is  imperative.  To 
accomplish  this  facet  of  interoperability, 
a  data  model  and  formal  ontology  are 
being  developed.  Eight  high-level  cate¬ 
gories  and  respective  sub-elements  have 
been  identified  based  on  doctrinal 
review,  needs  analysis  utilizing  input 
from  military  subject  matter  experts,  and 
functional  decomposition  of  tasks  rele¬ 
vant  to  assured  mobility  based  on  the 
Army  Universal  Task  List.  A  significant 
component  of  the  remaining  work 
involves  determining  which  elements  are 
unique  to  the  Mobility-COP  ontology 
and  which  are  available  from  existing  or 
emerging  ontology  development.  The 
results  will  be  continuously  vetted  with 
the  community  and  cross-checked  with 
other  existing  ontology,  data  model,  and 
standards  development  efforts.  ♦ 
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Notes 

1.  The  DoD  Metadata  registry  and  the 
Metadata  Specification  can  be  found 
at:  <http:/  / diides.ncr.disa.mil/ mdreg 
HomePage/ mdregHome.portal>. 

2.  The  C2IEDM  documentation  is 
available  at  <http://www.mip-site. 
org/>. 

3.  Reasoner:  Something  that  can  find 
new  facts  from  existing  data  (also 
known  as  reasoning)  <http://en. 
wikipedia.org/wiki/Reasoner>.  See 
<http:  /  /  www.w3.org/2004/ 
OWL/ >  for  a  list  of  available  reason- 
ers. 

4.  See  the  Environmental  Data  Coding 
Specification  at  <http://sedris.org> 
for  exact  definitions. 

5.  Area  feature  type  (in  this  case  a  mine¬ 
field)  is  a  property  of  an  areal  primi¬ 
tive  feature,  other  properties  of  the 
primitive  feature  contain  the  location 
and  extent  information  (see  <www. 
sedris.org/ drm.htm>). 
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